الواجهات الأمامية المصغرة (Micro-Frontends): إتقان بنية اتحاد الوحدات (Module Federation)

في مشهد تطوير الويب سريع التطور اليوم، يمكن أن يصبح بناء وصيانة تطبيقات الواجهات الأمامية واسعة النطاق أمرًا معقدًا بشكل متزايد. غالبًا ما تؤدي البنى المترابطة التقليدية (monolithic) إلى تحديات مثل تضخم الكود، وأوقات بناء بطيئة، وصعوبات في عمليات النشر المستقلة. تقدم الواجهات الأمامية المصغرة حلاً عن طريق تقسيم الواجهة الأمامية إلى أجزاء أصغر وأكثر قابلية للإدارة. تتعمق هذه المقالة في اتحاد الوحدات (Module Federation)، وهي تقنية قوية لتنفيذ الواجهات الأمامية المصغرة، مستكشفةً فوائدها وبنيتها واستراتيجيات تنفيذها العملية.

ما هي الواجهات الأمامية المصغرة؟

الواجهات الأمامية المصغرة هي نمط معماري يتم فيه تقسيم تطبيق الواجهة الأمامية إلى وحدات أصغر ومستقلة وقابلة للنشر. عادةً ما يكون كل واجهة أمامية مصغرة مملوكة لفريق منفصل، مما يسمح باستقلالية أكبر ودورات تطوير أسرع. يعكس هذا النهج بنية الخدمات المصغرة (microservices) المستخدمة بشكل شائع في الواجهة الخلفية.

تشمل الخصائص الرئيسية للواجهات الأمامية المصغرة ما يلي:

• قابلية النشر المستقلة: يمكن نشر كل واجهة أمامية مصغرة بشكل مستقل دون التأثير على الأجزاء الأخرى من التطبيق.
• استقلالية الفرق: يمكن لفرق مختلفة امتلاك وتطوير واجهات أمامية مصغرة مختلفة باستخدام التقنيات وسير العمل المفضل لديهم.
• تنوع التقنيات: يمكن بناء الواجهات الأمامية المصغرة باستخدام أطر عمل ومكتبات مختلفة، مما يسمح للفرق باختيار أفضل الأدوات للمهمة.
• العزل: يجب عزل الواجهات الأمامية المصغرة عن بعضها البعض لمنع الأعطال المتتالية وضمان الاستقرار.

لماذا نستخدم الواجهات الأمامية المصغرة؟

يوفر اعتماد بنية الواجهات الأمامية المصغرة العديد من المزايا الهامة، خاصة للتطبيقات الكبيرة والمعقدة:

• تحسين قابلية التوسع: تقسيم الواجهة الأمامية إلى وحدات أصغر يجعل من السهل توسيع نطاق التطبيق حسب الحاجة.
• دورات تطوير أسرع: يمكن للفرق المستقلة العمل بالتوازي، مما يؤدي إلى دورات تطوير وإصدار أسرع.
• زيادة استقلالية الفرق: تتمتع الفرق بمزيد من التحكم في الكود الخاص بها ويمكنها اتخاذ القرارات بشكل مستقل.
• صيانة أسهل: قواعد الكود الأصغر أسهل في الصيانة وتصحيح الأخطاء.
• غير مقيدة بتقنية معينة (Technology Agnostic): يمكن للفرق اختيار أفضل التقنيات لاحتياجاتها الخاصة، مما يسمح بالابتكار والتجريب.
• تقليل المخاطر: تكون عمليات النشر أصغر وأكثر تكرارًا، مما يقلل من مخاطر الأعطال واسعة النطاق.

مقدمة إلى اتحاد الوحدات (Module Federation)

اتحاد الوحدات (Module Federation) هي ميزة تم تقديمها في Webpack 5 تسمح لتطبيقات جافاسكريبت بتحميل الكود ديناميكيًا من تطبيقات أخرى في وقت التشغيل. وهذا يتيح إنشاء واجهات أمامية مصغرة مستقلة وقابلة للتركيب حقًا. بدلاً من بناء كل شيء في حزمة واحدة، يسمح اتحاد الوحدات للتطبيقات المختلفة بمشاركة واستهلاك وحدات بعضها البعض كما لو كانت تبعيات محلية.

على عكس الأساليب التقليدية للواجهات الأمامية المصغرة التي تعتمد على iframes أو مكونات الويب (web components)، يوفر اتحاد الوحدات تجربة أكثر سلاسة وتكاملًا للمستخدم. إنه يتجنب الحمل الزائد على الأداء والتعقيد المرتبط بهذه التقنيات الأخرى.

كيف يعمل اتحاد الوحدات

يعمل اتحاد الوحدات على مفهوم "كشف" (exposing) و "استهلاك" (consuming) الوحدات. يمكن لتطبيق واحد ("المضيف" أو "الحاوية") كشف الوحدات، بينما يمكن للتطبيقات الأخرى ("البعيدة" أو "remotes") استهلاك هذه الوحدات المكشوفة. إليك تفصيل للعملية:

1. كشف الوحدة (Module Exposure): تقوم واجهة أمامية مصغرة، تم تكوينها كتطبيق "بعيد" (remote) في Webpack، بكشف وحدات معينة (مكونات، دوال، أدوات مساعدة) من خلال ملف تكوين. يحدد هذا التكوين الوحدات التي سيتم مشاركتها ونقاط الدخول المقابلة لها.
2. استهلاك الوحدة (Module Consumption): تقوم واجهة أمامية مصغرة أخرى، تم تكوينها كتطبيق "مضيف" (host) أو "حاوية" (container)، بالإعلان عن التطبيق البعيد كتبعية. تحدد عنوان URL حيث يمكن العثور على بيان اتحاد الوحدات للتطبيق البعيد (ملف JSON صغير يصف الوحدات المكشوفة).
3. التحليل في وقت التشغيل (Runtime Resolution): عندما يحتاج التطبيق المضيف إلى استخدام وحدة من التطبيق البعيد، فإنه يجلب ديناميكيًا بيان اتحاد الوحدات للتطبيق البعيد. يقوم Webpack بعد ذلك بحل تبعية الوحدة وتحميل الكود المطلوب من التطبيق البعيد في وقت التشغيل.
4. مشاركة الكود (Code Sharing): يسمح اتحاد الوحدات أيضًا بمشاركة الكود بين التطبيقات المضيفة والبعيدة. إذا كان كلا التطبيقين يستخدمان نفس الإصدار من تبعية مشتركة (مثل React، lodash)، فسيتم مشاركة الكود، مما يتجنب التكرار ويقلل من أحجام الحزم.

إعداد اتحاد الوحدات: مثال عملي

لنوضح اتحاد الوحدات بمثال بسيط يتضمن واجهتين أماميتين مصغرتين: "كتالوج المنتجات" و "عربة التسوق". سيكشف كتالوج المنتجات عن مكون قائمة المنتجات، والذي ستستهلكه عربة التسوق لعرض المنتجات ذات الصلة.

هيكل المشروع

  
  micro-frontend-example/
    product-catalog/
      src/
        components/
          ProductList.jsx
        index.js
        webpack.config.js
    shopping-cart/
      src/
        components/
          RelatedProducts.jsx
        index.js
        webpack.config.js
  

كتالوج المنتجات (تطبيق بعيد - Remote)

webpack.config.js

  
  const { ModuleFederationPlugin } = require('webpack').container;
  const path = require('path');

  module.exports = {
    // ... other webpack configurations
    plugins: [
      new ModuleFederationPlugin({
        name: 'product_catalog',
        filename: 'remoteEntry.js',
        exposes: {
          './ProductList': './src/components/ProductList',
        },
        shared: {
          react: { singleton: true, eager: true, requiredVersion: '^17.0.0' },
          'react-dom': { singleton: true, eager: true, requiredVersion: '^17.0.0' },
        },
      }),
    ],
  };
  

شرح:

• name: الاسم الفريد للتطبيق البعيد.
• filename: اسم ملف نقطة الدخول الذي سيتم كشفه. يحتوي هذا الملف على بيان اتحاد الوحدات.
• exposes: يحدد الوحدات التي سيكشفها هذا التطبيق. في هذه الحالة، نكشف عن مكون `ProductList` من `src/components/ProductList.jsx` تحت اسم `./ProductList`.
• shared: يحدد التبعيات التي يجب مشاركتها بين التطبيقات المضيفة والبعيدة. هذا أمر حاسم لتجنب تكرار الكود وضمان التوافق. `singleton: true` يضمن تحميل نسخة واحدة فقط من التبعية المشتركة. `eager: true` يقوم بتحميل التبعية المشتركة بشكل أولي، مما يمكن أن يحسن الأداء. `requiredVersion` يحدد نطاق الإصدار المقبول للتبعية المشتركة.

src/components/ProductList.jsx

  
  import React from 'react';

  const ProductList = ({ products }) => (
    

      {products.map((product) => (
        
{product.name} - ${product.price}
      ))}
    
  );

  export default ProductList;
  

عربة التسوق (تطبيق مضيف - Host)

webpack.config.js

  
  const { ModuleFederationPlugin } = require('webpack').container;
  const path = require('path');

  module.exports = {
    // ... other webpack configurations
    plugins: [
      new ModuleFederationPlugin({
        name: 'shopping_cart',
        remotes: {
          product_catalog: 'product_catalog@http://localhost:3001/remoteEntry.js',
        },
        shared: {
          react: { singleton: true, eager: true, requiredVersion: '^17.0.0' },
          'react-dom': { singleton: true, eager: true, requiredVersion: '^17.0.0' },
        },
      }),
    ],
  };
  

شرح:

• name: الاسم الفريد للتطبيق المضيف.
• remotes: يحدد التطبيقات البعيدة التي سيستهلك هذا التطبيق وحدات منها. في هذه الحالة، نعلن عن تطبيق بعيد باسم `product_catalog` ونحدد عنوان URL حيث يمكن العثور على ملف `remoteEntry.js` الخاص به. التنسيق هو `remoteName: 'remoteName@remoteEntryUrl'`.
• shared: على غرار التطبيق البعيد، يحدد التطبيق المضيف أيضًا تبعياته المشتركة. هذا يضمن أن التطبيقات المضيفة والبعيدة تستخدم إصدارات متوافقة من المكتبات المشتركة.

src/components/RelatedProducts.jsx

  
  import React, { useEffect, useState } from 'react';
  import ProductList from 'product_catalog/ProductList';

  const RelatedProducts = () => {
    const [products, setProducts] = useState([]);

    useEffect(() => {
      // Fetch related products data (e.g., from an API)
      const fetchProducts = async () => {
        // Replace with your actual API endpoint
        const response = await fetch('https://fakestoreapi.com/products?limit=3');
        const data = await response.json();
        setProducts(data);
      };

      fetchProducts();
    }, []);

    return (
      

        
Related Products
        {products.length > 0 ?  : 
Loading...
}
      
    );
  };

  export default RelatedProducts;
  

شرح:

• import ProductList from 'product_catalog/ProductList'; هذا السطر يستورد مكون `ProductList` من التطبيق البعيد `product_catalog`. الصيغة `remoteName/moduleName` تخبر Webpack بجلب الوحدة من التطبيق البعيد المحدد.
• يستخدم المكون بعد ذلك مكون `ProductList` المستورد لعرض المنتجات ذات الصلة.

تشغيل المثال

1. ابدأ تشغيل كل من تطبيقي "كتالوج المنتجات" و "عربة التسوق" باستخدام خوادم التطوير الخاصة بهما (مثل `npm start`). تأكد من أنهما يعملان على منافذ مختلفة (على سبيل المثال، كتالوج المنتجات على المنفذ 3001 وعربة التسوق على المنفذ 3000).
2. انتقل إلى تطبيق عربة التسوق في متصفحك.
3. يجب أن ترى قسم المنتجات ذات الصلة، والذي يتم عرضه بواسطة مكون `ProductList` من تطبيق كتالوج المنتجات.

مفاهيم متقدمة في اتحاد الوحدات

بالإضافة إلى الإعداد الأساسي، يقدم اتحاد الوحدات العديد من الميزات المتقدمة التي يمكن أن تعزز بنية الواجهات الأمامية المصغرة لديك:

مشاركة الكود والإصدارات

كما هو موضح في المثال، يسمح اتحاد الوحدات بمشاركة الكود بين التطبيقات المضيفة والبعيدة. يتم تحقيق ذلك من خلال خيار التكوين `shared` في Webpack. من خلال تحديد التبعيات المشتركة، يمكنك تجنب تكرار الكود وتقليل أحجام الحزم. يعد تحديد إصدارات التبعيات المشتركة بشكل صحيح أمرًا بالغ الأهمية لضمان التوافق ومنع التعارضات. يعد الترقيم الدلالي (Semantic versioning - SemVer) معيارًا مستخدمًا على نطاق واسع لترقيم البرامج، مما يسمح لك بتحديد نطاقات إصدار متوافقة (على سبيل المثال، `^17.0.0` يسمح بأي إصدار أكبر من أو يساوي 17.0.0 ولكن أقل من 18.0.0).

التطبيقات البعيدة الديناميكية (Dynamic Remotes)

في المثال السابق، كان عنوان URL للتطبيق البعيد مكتوبًا بشكل ثابت في ملف `webpack.config.js`. ومع ذلك، في العديد من السيناريوهات الواقعية، قد تحتاج إلى تحديد عنوان URL للتطبيق البعيد ديناميكيًا في وقت التشغيل. يمكن تحقيق ذلك باستخدام تكوين بعيد قائم على promise:

  
  // webpack.config.js
  remotes: {
    product_catalog: new Promise(resolve => {
      // Fetch the remote URL from a configuration file or API
      fetch('/config.json')
        .then(response => response.json())
        .then(config => {
          const remoteUrl = config.productCatalogUrl;
          resolve(`product_catalog@${remoteUrl}/remoteEntry.js`);
        });
    }),
  },
  

هذا يسمح لك بتكوين عنوان URL للتطبيق البعيد بناءً على البيئة (مثل التطوير، الاختبار، الإنتاج) أو عوامل أخرى.

تحميل الوحدات غير المتزامن

يدعم اتحاد الوحدات تحميل الوحدات بشكل غير متزامن، مما يسمح لك بتحميل الوحدات عند الطلب. يمكن أن يؤدي ذلك إلى تحسين وقت التحميل الأولي لتطبيقك عن طريق تأجيل تحميل الوحدات غير الحرجة.

  
  // RelatedProducts.jsx
  import React, { Suspense, lazy } from 'react';

  const ProductList = lazy(() => import('product_catalog/ProductList'));

  const RelatedProducts = () => {
    return (
      

        
Related Products
        Loading...
}>
          
        
      
    );
  };
  

باستخدام `React.lazy` و `Suspense`، يمكنك تحميل مكون `ProductList` بشكل غير متزامن من التطبيق البعيد. يوفر مكون `Suspense` واجهة مستخدم بديلة (مثل مؤشر تحميل) أثناء تحميل الوحدة.

الأنماط والأصول الموحدة

يمكن أيضًا استخدام اتحاد الوحدات لمشاركة الأنماط والأصول بين الواجهات الأمامية المصغرة. يمكن أن يساعد ذلك في الحفاظ على شكل ومظهر متسق عبر تطبيقك.

لمشاركة الأنماط، يمكنك كشف وحدات CSS أو المكونات المصممة (styled components) من تطبيق بعيد. لمشاركة الأصول (مثل الصور والخطوط)، يمكنك تكوين Webpack لنسخ الأصول إلى موقع مشترك ثم الإشارة إليها من التطبيق المضيف.

أفضل الممارسات لاتحاد الوحدات

عند تنفيذ اتحاد الوحدات، من المهم اتباع أفضل الممارسات لضمان بنية ناجحة وقابلة للصيانة:

• تحديد حدود واضحة: حدد بوضوح الحدود بين الواجهات الأمامية المصغرة لتجنب الاقتران الوثيق وضمان قابلية النشر المستقلة.
• إنشاء بروتوكولات اتصال: حدد بروتوكولات اتصال واضحة بين الواجهات الأمامية المصغرة. ضع في اعتبارك استخدام ناقل الأحداث (event buses) أو مكتبات إدارة الحالة المشتركة أو واجهات برمجة التطبيقات المخصصة.
• إدارة التبعيات المشتركة بعناية: قم بإدارة التبعيات المشتركة بعناية لتجنب تعارض الإصدارات وضمان التوافق. استخدم الترقيم الدلالي وفكر في استخدام أداة لإدارة التبعيات مثل npm أو yarn.
• تنفيذ معالجة قوية للأخطاء: نفذ معالجة قوية للأخطاء لمنع الأعطال المتتالية وضمان استقرار تطبيقك.
• مراقبة الأداء: راقب أداء واجهاتك الأمامية المصغرة لتحديد الاختناقات وتحسين الأداء.
• أتمتة عمليات النشر: قم بأتمتة عملية النشر لضمان عمليات نشر متسقة وموثوقة.
• استخدام نمط ترميز متسق: افرض نمط ترميز متسقًا عبر جميع الواجهات الأمامية المصغرة لتحسين قابلية القراءة والصيانة. يمكن أن تساعد أدوات مثل ESLint و Prettier في ذلك.
• توثيق بنيتك المعمارية: وثّق بنية الواجهات الأمامية المصغرة الخاصة بك لضمان فهم جميع أعضاء الفريق للنظام وكيفية عمله.

اتحاد الوحدات مقابل أساليب الواجهات الأمامية المصغرة الأخرى

في حين أن اتحاد الوحدات هو تقنية قوية لتنفيذ الواجهات الأمامية المصغرة، إلا أنه ليس النهج الوحيد. تشمل الطرق الشائعة الأخرى ما يلي:

• Iframes: توفر Iframes عزلًا قويًا بين الواجهات الأمامية المصغرة، ولكن قد يكون من الصعب دمجها بسلاسة ويمكن أن يكون لها حمل زائد على الأداء.
• مكونات الويب (Web Components): تتيح لك مكونات الويب إنشاء عناصر واجهة مستخدم قابلة لإعادة الاستخدام يمكن استخدامها عبر واجهات أمامية مصغرة مختلفة. ومع ذلك، يمكن أن يكون تنفيذها أكثر تعقيدًا من اتحاد الوحدات.
• التكامل في وقت البناء (Build-Time Integration): يتضمن هذا النهج بناء جميع الواجهات الأمامية المصغرة في تطبيق واحد في وقت البناء. في حين أنه يمكن أن يبسط النشر، إلا أنه يقلل من استقلالية الفريق ويزيد من مخاطر التعارضات.
• Single-SPA: هو إطار عمل يسمح لك بدمج تطبيقات متعددة من صفحة واحدة في تطبيق واحد. يوفر نهجًا أكثر مرونة من التكامل في وقت البناء ولكنه قد يكون أكثر تعقيدًا في الإعداد.

يعتمد اختيار النهج الذي سيتم استخدامه على المتطلبات المحددة لتطبيقك وحجم وهيكل فريقك. يقدم اتحاد الوحدات توازنًا جيدًا بين المرونة والأداء وسهولة الاستخدام، مما يجعله خيارًا شائعًا للعديد من المشاريع.

أمثلة واقعية على اتحاد الوحدات

في حين أن تطبيقات الشركات المحددة غالبًا ما تكون سرية، فإن المبادئ العامة لاتحاد الوحدات يتم تطبيقها عبر مختلف الصناعات والسيناريوهات. إليك بعض الأمثلة المحتملة:

• منصات التجارة الإلكترونية: يمكن لمنصة تجارة إلكترونية استخدام اتحاد الوحدات لفصل أقسام مختلفة من الموقع، مثل كتالوج المنتجات، وعربة التسوق، وعملية الدفع، وإدارة حساب المستخدم، إلى واجهات أمامية مصغرة منفصلة. يتيح ذلك لفرق مختلفة العمل على هذه الأقسام بشكل مستقل ونشر التحديثات دون التأثير على بقية المنصة. على سبيل المثال، قد يركز فريق في *ألمانيا* على كتالوج المنتجات بينما يدير فريق في *الهند* عربة التسوق.
• تطبيقات الخدمات المالية: يمكن لتطبيق خدمات مالية استخدام اتحاد الوحدات لعزل الميزات الحساسة، مثل منصات التداول وإدارة الحسابات، في واجهات أمامية مصغرة منفصلة. يعزز هذا الأمان ويسمح بالتدقيق المستقل لهذه المكونات الهامة. تخيل فريقًا في *لندن* متخصصًا في ميزات منصة التداول وفريقًا آخر في *نيويورك* يتولى إدارة الحسابات.
• أنظمة إدارة المحتوى (CMS): يمكن لنظام إدارة المحتوى استخدام اتحاد الوحدات للسماح للمطورين بإنشاء ونشر وحدات مخصصة كواجهات أمامية مصغرة. يتيح ذلك مرونة وتخصيصًا أكبر لمستخدمي نظام إدارة المحتوى. يمكن لفريق في *اليابان* بناء وحدة معرض صور متخصصة، بينما ينشئ فريق في *البرازيل* محرر نصوص متقدم.
• تطبيقات الرعاية الصحية: يمكن لتطبيق رعاية صحية استخدام اتحاد الوحدات لدمج أنظمة مختلفة، مثل السجلات الصحية الإلكترونية (EHRs)، وبوابات المرضى، وأنظمة الفوترة، كواجهات أمامية مصغرة منفصلة. يحسن هذا قابلية التشغيل البيني ويسمح بدمج أسهل للأنظمة الجديدة. على سبيل المثال، يمكن لفريق في *كندا* دمج وحدة جديدة للرعاية الصحية عن بعد، بينما يركز فريق في *أستراليا* على تحسين تجربة بوابة المريض.

الخاتمة

يوفر اتحاد الوحدات نهجًا قويًا ومرنًا لتنفيذ الواجهات الأمامية المصغرة. من خلال السماح للتطبيقات بتحميل الكود ديناميكيًا من بعضها البعض في وقت التشغيل، فإنه يتيح إنشاء بنى واجهة أمامية مستقلة وقابلة للتركيب حقًا. في حين أنه يتطلب تخطيطًا وتنفيذًا دقيقين، فإن فوائد زيادة قابلية التوسع، ودورات التطوير الأسرع، والاستقلالية الأكبر للفرق تجعله خيارًا مقنعًا لتطبيقات الويب الكبيرة والمعقدة. مع استمرار تطور مشهد تطوير الويب، يستعد اتحاد الوحدات للعب دور متزايد الأهمية في تشكيل مستقبل بنية الواجهات الأمامية.

من خلال فهم المفاهيم وأفضل الممارسات الموضحة في هذه المقالة، يمكنك الاستفادة من اتحاد الوحدات لبناء تطبيقات واجهة أمامية قابلة للتطوير والصيانة ومبتكرة تلبي متطلبات العالم الرقمي سريع الخطى اليوم.